Software control of bit-oriented serial data communications over half-duplex communications channels is common. As is known, such applications typically include a software-controlled terminal coupled to a synchronous modem via an interlace channel including an RTS signal, wherein the RTS signal controls the transmission status of the modem. In such an arrangement, the communications software needs to wait a period of time after writing the last data character to a bit-oriented serial communications controller (hereinafter "SCC") integrated circuit, such as the Zilog 8530, until the trailing cyclic redundancy check (hereinafter "CRC") characters and trailing flag characters have been sent from the SCC and any attached data communications equipment before setting the RTS signal to LOW, or "off."
In such an arrangement, after the software writes the last character to the SCC, the SCC generates a processor interrupt indicating that the end of message (hereinafter "EOM") has occurred. At this point, the software must wait the necessary amount of time before setting RTS off to prevent corrupting the trailing characters which validate the entire message. The amount of time is determined by the data character bit rate, namely, from 2400 bits per second ("bps") to 64,000 bps and is typically the time required to send 30 bits of data. At 2400 bps, 30 bit times equals 12.5 milliseconds. At 64,000 bps, the time required to send 30 bits of data equals 0.47 milliseconds. As the communications software does not know the data bit rate, waiting the correct amount of time is difficult.
There are two methods currently used to address this problem.
A first method, known as the "compute bound processing loop" approach, is described as follows. When the software receives the EOM interrupt, it enters a compute bound processing loop to delay the necessary amount of time before setting RTS to LOW. A typical compute loop is as follows:
Initialize a loop counter to a large value.
Top of Loop:
Decrement the loop counter. PA1 If the loop counter is greater than zero, go to Top of Loop. PA1 Set RTS off. PA1 (d1) form an error-check message having a first predetermined number of bits; PA1 (d2) send the error-check message to the shift register; PA1 (d3) form a second predetermined number based on the first predetermined number; and, PA1 (d4) send the second predetermined number to the counter; PA1 (e) determine when the counter reaches zero; and, PA1 (f) when the counter reaches zero, then set the RTS signal to LOW.
There are several problems with this approach, as follows. First, while the computer is in this compute bound loop, the computer is not available to perform other tasks. This is a very inefficient use of resources. Second, if the communications software is executed on multiple processors with different processing speeds, the loop counter cannot be set appropriately for all processor speeds. On a fast processor, the loop counter should be larger than on a slower processor. Third, if the communications software is executing at varying data character bit rates, the loop counter cannot be set appropriately for all bit rates. For a slow data bit rate, the loop counter should be larger than for a faster data bit rate.
A second method, known as the "hardware timer counter" approach, is described as follows. When the software receives the EOM interrupt, it initializes an external hardware timer counter to a specified value. The hardware timer counter decrements to zero at a rate determined by an external fixed oscillator. When the timer counter reaches zero, a hardware interrupt is generated. In response to this hardware interrupt, the software sets RTS to LOW.
There are several problems with the "hardware timer counter," as follows. First, the computer may not have a hardware timer counter available without incurring the extra cost of adding one. Second, the hardware timer counter which may be available in the computer may be the wrong frequency to achieve the timing granularity required. Third, the hardware timer counters which are available in the computer may be clocked at an unknown frequency. Fourth, if the communications software is executing at varying unknown data bit rates, the hardware timer counter cannot be set appropriately for all bit rates.
Thus, there is a need for a method for controlling the RTS signal in such an arrangement.